Issues/430 custom serializers: Allow for custom serialization on all things stored in cache backend to mitigate security and performance problems #431
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #430 and pave the path for #427 This PR adds two interfaces:
The ObjectIOFactory just creates instances of the ObjectIOStrategy. The strategy is invoked when writing/reading anything objects from the the serialized stream that are not the session attributes.
This PR is implemented in a way so the current behavior is backwards compatible with older versions.
Why is this important: In the current codebase, ordinary ObjectInputStream/ObjectOutputStream are used to serialize various objects. This PR allows you to customize this process.
For full mitigation, both a SessionAttributesTranscoder and an ObjectIOStrategy (and their two factories) that perform serialization class filtering should be implemented.
In our case, we implemented a strategy that uses FST (https://github.com/fstpackage/fst), employs compression(https://github.com/lz4/lz4), encryption / signing / authentication ((https://github.com/martinwithaar/Encryptor4j), and Serialization class filtering (https://docs.oracle.com/en/java/javase/11/core/serialization-filtering1.html). As discussed in #427 this covers an attack vector in which bytecode injection is possible if other checks on the server fail.
We implemented these interfaces and they can be used like this in a
context.xml
: